<HTML><HEAD><TITLE>peer_queue_create(+Queue, +Peer, +QueueType, +Direction, +Event)</TITLE>
</HEAD><BODY>[ <A HREF="index.html">External Interface</A> | <A HREF="../../index.html">Reference Manual</A> | <A HREF="../../fullindex.html">Alphabetic Index</A> ]
<H1>peer_queue_create(+Queue, +Peer, +QueueType, +Direction, +Event)</H1>
Create a new peer queue Queue for Peer from ECLiPSe side.
<DL>
<DT><EM>Queue</EM></DT>
<DD>Name of peer queue (atom)
</DD>
<DT><EM>Peer</EM></DT>
<DD>Peer name (atom)
</DD>
<DT><EM>QueueType</EM></DT>
<DD>Queue type (sync or async)
</DD>
<DT><EM>Direction</EM></DT>
<DD>Queue direction (fromec, toec or bidirect)
</DD>
<DT><EM>Event</EM></DT>
<DD>Event for peer queue (atom or event handle)
</DD>
</DL>
<H2>Description</H2>
<P>
   Creates a new peer queue Queue for peer Peer from ECLiPSe
   side. The nature of queue created is specified by the other arguments
   (see the Embedding and interfacing manual for more details on peer queues):

<DL>
<DT>QueueType<DD>
      Type of the queue: either synchronous (sync) or asynchronous (async).

<DT>Direction<DD>
      Direction of the synchronous queue: either from ECLiPSe to remote
      (fromec) or to ECLiPSe from remote (toec). This argument is ignored
      for asynchronous queues, which are bidirectional.

<DT>Event<DD>
      Name or handle of event that will be raised on the ECLiPSe side when
      data arrives. Applicable only for data sent from remote side to ECLiPSe. 
      If Event is the empty atom '', then no event will be associated with
      the peer queue. 
</DL>
<P>
      This predicate will cause the queue to be created (if permitted by
      the remote side) on both the ECLiPSe and remote sides. Alternatively,
      the queue can be created from the remote side. Note in either case,
      the creation is done only on one side, and the created queue appears
      on the other side without an explicit creation there. Note also that
      if the queue is created on the ECLiPSe side, there is no way to name
      the handler on the remote side for data arriving on the remote side.
<P>
      In the case of a remote peer, the queue is connected by a socket
      connection between the two sides. The server socket is created on the
      ECLiPSe side, and it will wait at most TimeOut seconds for the remote
      side to make the connection. TimeOut is the time specified in
      remote_connect_accept/6 when the remote peer was created. In
      addition, when the client socket connection is accepted, ECLiPSe
      checks to ensure that the client's host is the same as the one that
      formed the attachment. If not, then the connection is from someone
      else, and ECLiPSe will reject and close the queue connection.
      
<H3>Modes and Determinism</H3><UL>
<LI>peer_queue_create(+, +, +, +, +) is semidet
</UL>
<H3>Fail Conditions</H3>
Peer is not a current peer.
<H3>Exceptions</H3>
<DL>
<DT><EM>(5) type error </EM>
<DD>QueueName, Peer or Event not of the correct type.
<DT><EM>(6) out of range </EM>
<DD>QueueType or Direction not of permitted values.
</DL>
<H2>See Also</H2>
<A HREF="../../kernel/externals/peer_queue_close-1.html">peer_queue_close / 1</A>, <A HREF="../../kernel/externals/peer_queue_get_property-3.html">peer_queue_get_property / 3</A>, <A HREF="../../kernel/externals/remote_connect_accept-6.html">remote_connect_accept / 6</A>, <A HREF="../../kernel/event/event_create-3.html">event_create / 3</A>
</BODY></HTML>
